前兩篇分別介紹了 RBAC(用角色管理權限)與 ABAC(用屬性動態判斷權限),兩者都是從「人」出發來思考權限。今天要介紹的兩種模型,則是從另外兩個角度出發:ACL(Access Control List,存取控制清單) 從「資源」出發,直接在每個資源上記錄誰能做什麼;ReBAC(Relationship-Based Access Control,關係型存取控制) 則從「關係」出發,依據 Subject 與 Resource 之間的關係來決定權限。
ACL 歷史悠久,ReBAC 則相對較新。前者適合直接、逐件設定資源權限,後者則更適合處理資料夾、團隊、共享這類層次化、關係密集的授權需求。
今天內容涵蓋:
ACL(Access Control List,存取控制清單)是一份附加在資源上的權限清單,用來記錄哪些 Subject 可以對這個資源執行哪些操作。每一筆記錄稱為 Access Control Entry(ACE),通常包含使用者或群組,以及允許或拒絕的操作。
例如,一個檔案的 ACL 寫著 (Gloria: read, write; Joanne: read),就代表 Gloria 可以讀寫這個檔案,Joanne 只能讀取。它與 RBAC 最大的差異在於:權限直接記錄在資源上,而不是先透過 Role 統一分配。
ACL 早在 1965 年便出現在 Multics 檔案系統中。直到今天,檔案系統、雲端儲存與網路設備仍廣泛使用相同概念。
| 系統/服務 | ACL 類型 | 主要用途 |
|---|---|---|
| Unix、Linux、macOS、Solaris | POSIX ACL | 設定使用者與群組對檔案的讀取、寫入與執行權限 |
| macOS、Solaris ZFS、FreeBSD | NFSv4 ACL | 提供比 POSIX ACL 更細緻的檔案權限設定 |
| Windows、Active Directory | DACL/SACL | 分別控制資源存取與記錄存取事件 |
| 路由器、交換器 | Network ACL | 依 IP、Port 等條件控制進出流量 |
其中兩個常見案例是:
ACL 與 RBAC 都是在回答「誰可以做什麼」,主要差別在於權限如何管理:ACL 將權限直接記錄在每個資源上;RBAC 則先將權限整理成 Role,再把 Role 指派給 User。兩者能處理的情境可能重疊,但適合的管理方式與規模不同。
| 比較項目 | ACL | RBAC |
|---|---|---|
| 存取控制依據 | 資源本身的權限清單 | 使用者被指派的 Role |
| 管理單位 | 逐個資源設定 | 逐個角色設定 |
| 優點 | 精細,可逐件控制 | 易於管理大量使用者 |
| 缺點 | 難以擴展(Hard to scale),資源多時維護成本高 | 細粒度不足時容易 Role Explosion |
| 適合情境 | 資源數量有限、需要逐件自訂權限(如檔案共享) | 使用者量大、職務結構清楚 |
Granular control(精細控制) 是 ACL 的強項,但 Hard to scale(難以擴展) 也是它最常被批評的地方。當系統有數百萬個檔案,而且每個檔案都有自己的權限清單時,維護成本會非常高。這也是接下來 ReBAC 想要改善的問題。
ReBAC(Relationship-Based Access Control,關係型存取控制) 是一種授權(Authorization)模式。它不只檢查 User 擁有什麼 Role 或屬性,而是改問:這個 User 與目標資源之間存在什麼關係?
例如,Gloria 想編輯「人事資料夾」中的薪資文件,系統可以依照下列關係判斷:
因此,Gloria 不必直接出現在薪資文件的權限清單中。系統只要沿著「Gloria → HR Team → 人事資料夾 → 薪資文件」這條關係,就能推導出 Gloria 可以編輯該文件。
ReBAC 會把 User、Team 與 Resource 視為節點,再以 Member、Editor、Parent 等關係將它們連接起來。系統收到請求時,會檢查是否存在符合 Policy 的關係路徑;找不到符合條件的路徑,就拒絕存取。
ReBAC 一詞於 2006 年提出;2019 年 Google 發表 Zanzibar 論文後,這種模型開始被廣泛用於文件共享、團隊協作與多租戶系統。
💡Relationship 只負責記錄關係,例如「HR Team 是人事資料夾的 Editor」。至於 Editor 可以讀取、修改或刪除哪些文件,則由 Policy 另外規定。
ReBAC 主要由三個概念組成:
最常見的 ReBAC 情境,就是像 Google Drive 一樣具有多層資料夾的共享檔案系統。

圖中包含兩種關係:
如果 Policy 規定「資料夾的 Owner 可以管理其下所有內容」,系統便能沿著資料夾階層推導出:Gloria 不只可以管理 Gloria's Files,也可以管理 1.jpg、2.jpg、CV.pdf 與 Data.xml。她不需要在每一個檔案上分別設定 ACL。
這些關係通常會以 Relationship Tuple(關係元組) 記錄。以下再加入 Joanne 作為 Documents 的 Viewer:
[
{ "subject": "user:gloria", "relation": "owner", "object": "folder:glorias-files" },
{ "subject": "user:joanne", "relation": "viewer", "object": "folder:documents" },
{ "subject": "folder:glorias-files", "relation": "parent", "object": "folder:documents" },
{ "subject": "folder:documents", "relation": "parent", "object": "file:cv.pdf" }
]
依照相同的繼承規則,Joanne 可以檢視 Documents 及其中的 CV.pdf、Data.xml,但不能存取 Photos 裡的圖片。這就是 ReBAC 的核心:先記錄人與資源之間的關係,再由 Policy 沿著關係推導權限。
| 比較方式 | RBAC | ReBAC |
|---|---|---|
| 主要判斷 | Gloria 擁有什麼 Role? | Gloria 與這個資源有什麼關係? |
| 判斷範例 | Gloria 是 Editor,因此可以使用編輯功能 | Gloria 是資料夾的 Owner,因此可以管理其中的檔案 |
| 權限範圍 | 通常控制一類功能或資源 | 通常控制某個特定檔案、資料夾或專案 |
| 適合情境 | 職務與權限相對固定的系統 | 文件共享、團隊協作與多層資料夾 |
| 調整方式 | 指派或移除 Role | 新增或移除 Owner、Viewer、Member 等關係 |
RBAC 和 ReBAC 不需要二選一。以文件系統為例,可以分成兩次判斷:
因此,RBAC 可以先管「能不能使用這類功能」,ReBAC 再管「能不能存取這個特定資源」。如果還要限制存取時間或公司網路,才另外加入 ABAC。
ReBAC 的主要挑戰可以整理成三點:
也就是說,ReBAC 適合處理複雜共享關係,但需要特別注意模型設計與查詢成本。
本篇的重點可以整理為:
下一篇將進入 Microsoft 的身分驗證平台,介紹 Azure AD B2C 與 Entra External ID 的關係,以及 Microsoft 外部使用者登入架構的演進。